(19) 



J) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(12) 



(11) EP 0 736 827 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 


pij mi oi. . vjvur i/wis, uuor w+o 


09.10.1996 Bulletin 1996/41 


(21) Application number: 96301503.7 




(22) Date of filing: 05.03.1996 




(84) Designated Contracting Stales: 


• Palmer, Thomas A. 


DE FR GB 


San Carlos, CA 94070 (US) 




• Pato, Joseph N. 


(30) Priority: 07.04.1995 US 422206 


Arlington, Ma 02174 (US) 




• Anderson, Anne H. 


(71) Applicant: Hewlett-Packard Company 


Acton, MA 01720 (US) 


Palo Alto, California 94304 (US) 


• Carpenter, Gregory P. 




Medford, Ma 02155 (US) 


(72) Inventors: 




• Klemba, Keith S. 


(74) Representative: Williams, John Francis et al 


Santa Clara, CA 95051 (US) 


WILLIAMS, POWELL & ASSOCIATES 


• Crall, Christopher J. 


34 Tavistock Street 


Los Altos, CA 94022 (US) 


London WC2E 7PB (GB) 



(54) Security administration for electronic data processing 



(57) An object oriented tool monitors the step-by- 
step progress of security administration within an elec- 
tronic work flow to implement access control measures, 
and security administration policies that may include ad- 
ditional checks and balances, such as second party re- 
view, escalated authorization requirements, and trusted 
audit facilities. A security administration architecture for 
distributed electronic data processing systems prefera- 
bly includes a checkpoint object that provides uniform 
characterization of milestone or transition states in ad- 
ministration activity, and which may be inherited by or 
refined to an administration activity object. A checkpoint 
object manager that is instantiated as a trusted third par- 
ty object manages the state progression of checkpoint 
objects. Asa result of checkpointing; checkpoint objects 
are resumed with their state advanced, reversed, or un- 
changed by the checkpoint object manager as appropri- 
ate. The checkpoint object manager also assures that 
all checkpoints are logged and monitored, and that re- 
sumptions are authenticated. 
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Description 

The present invention relates to security adminis- 
tration tor electronic data processing systems. More 
particularly, the present invention relates to a method- 
ology that employs an object-oriented paradigm to gov- 
ern a step-by-step security administration process for 
an electronic data processing system. 

The banking industry often requires that the approv- 
al of more than one authorized person be provided when 
certain tasks are performed. This is referred to as a two- 
party system. For example, if a bank customer wants to 
cash a check for $1 0,000, the teller to whom the check 
is presented may need to have a second bank employ- 
ee, e.g. a supervisor, approve the check. Just as the 
banking industry requires a two-party system for certain 
levels of security administration, such security adminis- 
tration is also required by various other industries, e.g. 
telephone companies, for example when establishing 
new telephone numbers. 

This two-party approach is also necessary for trans- 
actions that involve electronic information, especially as 
such electronic transactions become increasingly com- 
monplace. For example, it is desirable to be able to per- 
form an electronic task to a certain point and then freeze 
that task until the task related transaction can be verified 
and/or authorized by an appropriate person. That is, 
someone in authority must approve the transaction at 
its present stage before it may be moved on to the next 
step. 

Related to such two-party systems is the concept 
of work flow. For example, certain software products 
provide a work flow in which a first person performs a 
particular task for a period of time and then another per- 
son continues the task for a period of time. Thereafter, 
the task may be performed by yet other persons until, 
at some point, it returns to the first person. Such work 
flow has a security administration element when a per- 
son performing a task must break at a defined point, at 
which time a next level manager, i.e. someone with ap- 
propriate authority and accountability, completes the 
task at that level, e.g. by approving a transaction, before 
the task can be moved to the next step. 

The architecture of such security administration is 
just as important as that of security measures them- 
selves. For example, if locks are put on all the doors, 
but the keys are given out indiscriminately it doesn't mat- 
ter how good the locks are. In an electronic data 
processing system, it may be possible to provide the ap- 
pearance of proper two-party authorization through em- 
ployee collusion or fraud. Consequently, it is necessary 
to have a comprehensive tool for governing the admin- 
istration of security policies in the context of electronic 
work flow. 

The invention provides an object oriented tool that 
monitors the step-by-step progress of security adminis- 
tration within an electronic work flow. In addition to ac- 
cess control measures, security administration policies 



implemented by the invention may include additional 
checks and balances, such as second party review, es- 
calated authorization requirements, and trusted audit fa- 
cilities. Thus, the invention provides a security adminis- 
5 tration architecture for distributed electronic data 
processing systems. 

The architecture preferably includes: 

A checkpoint object that provides uniform charac- 
terization of milestone or transition states in admin- 
istration activity. This object class definition is de- 
signed to be inherited by or refined to an adminis- 
tration activity object. For example, an InstalMJser 
object might inherit a Checkpoint_Object class, 
such that the InstallJJser activity must checkpoint 
at a final stage of installation to obtain second party 
approval before installation may be completed; and 

A checkpoint object manager which is instantiated 
as a trusted third party object that manages the 
state progression of checkpoint objects. For exam- 
ple, objects that possess Checkpoint_Object calls 
are able to checkpoint their activities to the 
Checkpoint_Object_Manager_Object. As a result 
of checkpointing, the checkpointed objects are re- 
sumed with their state advanced, reversed, or un- 
changed by the checkpoint object manager as ap- 
propriate. The checkpoint object manager also as- 
sures that all checkpoints are logged and moni- 
tored, and that resumptions are authenticated. 

Because the checkpoint object and checkpoint ob- 
ject manager are object oriented, it is possible to inherit 
into each object an object class, i.e. the check point ob- 
ject, having any desired security administration at- 
tributes. Any object that has these attributes, or that has 
inherited this class, can then be managed by the check- 
point object manager. In this way, a task may be per- 
formed until it reaches a checkpoint, at which time the 
process can check-in an object to the checkpoint object 
manager Once checked-in, the object cannot be 
checked-out unless certain criteria that implement se- 
curity administration policies are met. The checkpoint 
object also allows a person to suspend work on a task, 
for example to take a break, and the work may not re- 
sumed, except as authorized. 

Furthermore, failure to resume a suspended task, 
either by receiving authorization from an authorized per- 
son or by returning to the task within a predetermined 
time, may provide a system alert in which the checkpoint 
object manager escalates the checkpoint object. 

The invention will be explained by reference to ex- 
emplary embodiments which are described with refer- 
ence to the accompanying drawings, in which: 

Fig. 1 is a block diagram of a security administration 
architecture tor a distributed electronic data 
processing system according to the invention; 
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Fig. 2 is a block diagram of a checkpoint objecl ac- 
cording to the invention; 

Fig. 3 is a is a block diagram of a checkpoint object 
manager object according to the invention; and 5 

Fig. 4 is an architectural overview of a security ad- 
ministration system according to the invention. 

The embodiment provides an object oriented tool io 
consisting of a checkpoint object and a checkpoint ob- 
ject manager that comprise a system which continually 
monitors the step-by-step progress of security adminis- 
tration within an electronic work flow. In addition to ac- 
cess control measures, the invention implements secu- is 
rity administration policies that may include additional 
checks and balances, such as second party review, es- 
calated authorization requirements, and trusted audit fa- 
cilities. Because the checkpoint object and checkpoint 
object manager are object oriented : it is possible to in- 20 
herit into each object an object class, i.e. the checkpoint 
object, having any desired security administration at- 
tributes. Any object that has these attributes, or that has 
inherited this class, is managed by the checkpoint object 
manager. 2s 

In the system herein disclosed, execution of a task 
can proceed to a certain point, at which point the proc- 
ess can check- in a checkpoint object with the check- 
point object manager. The checkpoint object cannot be 
checked-out f rom the checkpoint object manager unless 30 
certain criteria that implement security administration 
policies are met. The use of a checkpoint object also 
allows one to suspend work on a task, for example to 
take a break, and the work may not resumed, except as 
authorized. Furthermore, failure to resume a suspended 35 
task, either by receiving authorizatbn from an author- 
ized person and/or by returning to the task within a pre- 
determined time, may provide a system alert in which 
the checkpoint object manager escalates the check- 
point object. 40 

Fig. 1 is a block diagram of a security administration 
architecture for a distributed electronic data processing 
system. The architecture consists of one or more clients 
10, a security server 20 : and a datastore 30, ail of which 
are distributed across an electronic network 40. 45 

Each client 10 may include: 

o A checkpoint object 1 5 that provides uniform char- 
acterization of milestone or transition states in se- 
curity administration activity, and that may be inner- so 
ited by or refined to an administration activity object. 
For example, an InstalUUser object might inherit a 
Checkpoint_Object class, i.e. it can become a 
checkpoint object, such that the InstalMJser activity 
must checkpoint at a final stage of installation to ob- ss 
tain second party approval before installation may 
be completed. 
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The security server 20 may include: 

o A checkpoint object manager 25 which is instanti- 
ated as a trusted third party object that manages 
the state progression of the checkpoint objects 1 5. 
For example, objects that possess 
Checkpoint_Object calls, i.e. checkpoint objects, 
are able to checkpoint their activities to the 
Checkpoint_Object_Manager_Object, i.e. the 
checkpoint object manager. As a result of check- 
pointing, the checkpointed objects are resumed 
with their state advanced, reversed, or unchanged 
by the checkpoint object manager, as appropriate, 
and consistent with local security administration 
policies. The checkpoint object manager assures 
that all checkpoints are logged and monitored, and 
that resumptions are authenticated. 

The preferred embodiment of the invention is imple- 
mented using object-oriented programming techniques. 
Such techniques are well known to those skilled in the 
art. See, for example Object-Oriented Systems Analy- 
sis , Shlaer and Mellor, Yourdon Press (1988); and The 
Electrical Engineering Handbook , Dorf, CRC Press 
(1993). 

In object-oriented systems, abstractions are pro- 
duced that correspond to sets of things. These things 
are referred to as objects. Each object has a set of at- 
tributes which describe the object's characteristics. A 
specific occurrence of an object, in which the object's 
attributes are populated with data, is referred to as an 
instance. All instances within a set of instances have the 
same characteristics and are subject to and conform to 
the same rules of behavior. Referential attributes are 
used to maintain the relationships between different ob- 
jects. 

An object-oriented paradigm is a programming par- 
adigm in which a system is modeled as a collection of 
self-contained objects that interact by sending messag- 
es. Objects are modules that contain both encapsulated 
data and all of the functions that are allowed to be per- 
formed on the encapsulated data. Objects are related 
to one another through an inheritance hierarchy 

In languages that support object-oriented program- 
ming, classes (i.e. data types) of objects are defined by 
specifying the variable that each object owns as in- 
stance variables, and operations, referred to as meth- 
ods, which are applicable to objects of the class. These 
methods are sent to an object as a message. Newobjets 
of a class are created, usually dynamically, by factory 
methods addressed to the class itself. These methods 
allocate the equivalent of a record having fields that are 
the instance variables of the object, and return a refer- 
ence to this record, which represents a new object. After 
its creation, an object can receive messages from other 
objects. 

In addition to data abstraction, object-oriented pro- 
gramming provides inheritance in which new subclass* 
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es are derived from an existing class by adding instance 
variables and/or methods. Each subclass inherits the in- 
stance variables and methods of its superclass. Ob- 
jects, which are instances of classes, may represent vis- 
ible objects. Actions applied to one objet may influence 
another object. In the context of the invention herein, 
the creation of a checkpoint object in accordance with 
a security administration policy, may cause the check- 
point object manager (which is itself an object) to take 
some action (such as notifying a supervisor that authen- 
tication or approval is required) that, in turn, allows the 
modification of checkpoint object (by resuming a sus- 
pended task). 

Fig. 2 is a block diagram of a checkpoint object 15 
according to the invention. The checkpoint object has a 
name CkPntObj 21 , attributes 22, and related actions 
23. 

The checkpoint object preferably has one or more 
of the following attributes: 

o Application! D - This attribute identifies the name of 
the application that sets the context for the check- 
point. Because the states of an application are likely 
to be similar for several applications, state informa- 
tion alone is not sufficient to identify the activity in 
the checkpoint object. Accordingly, an application 
identifier is also provided. 

o ApplCkPntState - This attribute indicates the state 
of a checkpoint object at the time of the checkpoint. 
See the "ApplResumeState" attribute for related 
state information. 

o ApplResumeState - This attribute indicates the 
state with which a checkpoint object should resume. 
This attribute is used by the checkpoint object man- 
ager (discussed below) to index into the authoriza- 
tion rule that applies to the present application. 

o ApplAuthRule - This attribute is a signed authoriza- 
tion rule that is used by the present application. 
These rules are generally indexed by states such 
that they govern the authorization entitlements as 
an application's activities progress. 

o CkPntTimeLimit - This attribute indicates the time 
limit that the checkpoint object may reside with the 
checkpoint manager. If this time limit is exceeded, 
the checkpoint manager issues an event to signal 
escalation of checkpoint attention. 

o CkPntObjMgrlD - This attribute records a list of all 
checkpoint object managers that have serviced this 
checkpoint object so far 

o CkPntDataPntrs[] - This attribute is a list of pointers 
to current checkpoint data. The checkpoint object 
manager does not understand the semantics of this 
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data. This data structure is stored as binary data by 
the checkpoint object manager. If the data comprise 
a pointer, then only a pointer is returned by the 
checkpoint object manager. If the data comprise the 
5 actual data, then the data are stored by the check- 
point object manager 

o CkPntSeal - This attribute is a trusted sea! of the 
current checkpoint object information. 

70 

The checkpoint object preferably has at least the 
following action: 

o Seal_CkPntobj() - This action computes the CkP- 
75 ntSeal attribute. Note that the seal covers all data 
of relevance in the context of the application. 

Fig. 3 is a is a block diagram of a checkpoint object 
manager 25 according to the invention. The checkpoint 
20 object manager has a name CkPntObjMgr 31 , attributes 
32, and related actions 33. 

The checkpoint object manager preferably has one 
or more of the following attributes: 

2S o ApplCkPntCount - This attribute is a count of the 
checkpoint objects that are currently checkpointed 
by the checkpoint object manager. 

o ApplCkPntListQ - This attribute is a non-ordered list 
30 of the checkpoint objects that are currently check- 
pointed by the checkpoint object manager. 

The checkpoint object manager preferably may 
take one or more of the following actions: 

35 

o Find() - This action searches the ApplCkPntList for 
objects that match the criteria of passed arguments. 

o Delete() - This action attempts to delete a check- 
40 pointed object. The authorization required for this 
action is not associated with the application context, 
but rather with administration entitlements for the 
checkpoint object manager. 

45 o CkPnt()- This action checkpoints an application ob- 
ject that contains the CkPntObj class behavior. 
Checkpointing a checkpoint object captures all 
CkPntObj attributes and checks the suspended 
checkpoint object in its present state into the CkP- 

50 ntObjMgr datastore. The checkpoint object manag- 
er CkPntObjMgr holds this data, and waits for the 
next application service to check out the checkpoint 
object , such that the application may resume 
processing. 

55 

o Resume() - This action passes all of the checkpoint 
object attributes for the identified checkpointed ob- 
ject to a calling object after first passing the author- 
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i/ation rules to the calling object. 

o RcportQ - This action produces one of several re- 
ports, including reports that are customized by 
passed arguments. Reports draw from checkpoint 
obiect manager log/audit files, as well as currently 
checkpointed data. 

Ftg 4 is an architectural overview of a security ad- 
ministration system according to the invention. Within 
the context of an system 55, there are several other 
lunchons including for example application developers 
46 pDhcy setters 45, managers 50, and security admin- 
istrators 47 (for example, in a two-party system, as dis- 
cussed nbove) Each function has an associated elec- 
tronic presence in a network 40. For example, this par- 
neuter embodiment of the invention resides in an elec- 
tronic data processing environment in which various us- 
ers 4? interact with application clients 41 to perform var- 
ious syslem tasks. Security administration policy is im- 
plemented in this embodiment of the invention by the 
application client to supervise user access, sign-on pro- 
cedures authorization and authentication, user privacy, 
and non repudiation. Any of these activities may gener- 
ate a checkpoint object that suspends the application 
clioni until the client state is advanced by a return from 
the checkpoint object manager that allows the client to 
proceed. 

Similarly, the application developers 46 are present 
via application servers 42 that implement security ad- 
ministration policy is implemented to supervise user ac- 
cess, sign-on procedures, authorization and authentica- 
tion, user privacy, and non-repudiation. As with applica- 
tion clients, any of these activities may generate a 
checkpoint object that suspends the application server 
until the server state is advanced by a return from the 
checkpoint object manager that allows the server to pro- 
ceed 

These same functions may also be implemented for 
managers 50 as management clients 43, and for secu- 
rity administrators 47 as security administration clients 
44. 

Within the realm of the policy setters 45 reside the 
network security servers 20 that include such functions 
as processing authorizations, providing an administra- 
tion server, providing a secure audit manager, perform- 
ing notary and time stamp functions, providing certifica- 
tion authority, implementing the checkpoint object man- 
ager, and various other functions, including providing a 
location for the datastore 30. ' 

Finally, the network 40 includes network manage- 
ment servers 48 that implement such network-related 
functions as providing a network map, providing an 
event monitor, allowing network management to config- 
ure the network, and providing network diagnostics. 

As discussed above, the invention provides a 
checkpoint object that suspends progress on a task until 
some action is taken by the checkpoint object manager 



with regard to the task. For example, a credit transaction 
cannot proceed until the transaction is approved by a 
supervisor. The checkpoint object also allows one to 
suspend work intentionally. For example, one may work- 
5 ing on a very important activity and it's lunch time. One 
would check the checkpoint object into the checkpoint 
object manager, i.e. the object is checkpointed, and then 
one could go to lunch. If the checkpoint object manager 
is not timely notified after a reasonable interval, the sys- 
tem recognizes that no one has checked the checkpoint 
object back out of the checkpoint object manager, and 
it escalates by sending out an alert to the effect that, 
"This was activity begun, and I'm waiting for someone 
to either pull it back out at the same level or for a man- 
ager to take it." 

The checkpoint object manager can monitor that no 
one is checking the checkpoint object out, even though 
the checkpoint object manager does not know the spe- 
cific semantics of the transaction in question, e.g. 
whether an account is being opened, a real estate deal 
is being cleared, or an employee is just going to lunch. 
The checkpoint object manager only knows that a 
checkpoint object has been checked in, that the check- 
point object has certain attributes and qualifiers, and 
that it is necessary to escalate the checkpoint object if 
someone having appropriate credentials does not check 
the checkpoint object out again. Furthermore, to check 
the checkpoint object out of the checkpoint object man- 
ager, it may be necessary to execute additional authen- 
tication schemes to prove that the person checking out 
the checkpoint object is the manager at the next level, 
or alternatively the person who checked the checkpoint 
object in in the first place to suspend the transaction. 

One important aspect of the invention is that the se- 
curity of the checkpoint object manager guarantees that 
the checkpoint object is not modified while it is checked 
in to the checkpoint object manager because the check- 
point object cannot be read while it is checked in. In fact, 
no one can read the checkpoint object at this point other 
than the next escalated person, or the person who 
checked in the checkpoint object, if rt was checked in to 
suspend the transaction temporarily. Therefore, no un- 
authorized individual can browse the checkpoint object. 
Thus, the invention provides a system that ensures the 
privacy and integrity of the system's task work flow, as 
well as information contained within the task. The inven- 
tion also provides a system that ensures that a task re- 
ceives proper attention, and that can escalate a task 
within an system's administration if the checkpoint ob- 
ject is not checked out by the proper person and/or with- 
in a predetermined period of time. 

Another important aspect of the invention is that it 
provides a system that deposits information. For exam- 
ple, the invention provides a system that includes a se- 
cure audit feature, e.g. if a customer is opening a new 
checking account and the task of opening the account 
requires a first person to create the account, then a su- 
pervisor must verify the account before the customer 
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has the account, i.e. a two-party system. One piece of 
information that leaves a trace behind is the time at 
which the account was checkpointed for approval and 
was approved. The checkpoint object manager makes 
an entry that indicates that the checkpoint object was 
checked in for checkpointing. The entry includes such 
information as the person from whom the checkpoint ob- 
ject was checked in and the time at which the checkpoint 
object was checked in. These entries are among the at- 
tributes of the checkpoint object which are discussed 
above. Accordingly, the checkpoint object manager 
faithfully records all relevant information connected with 
the transaction such that later an auditor can reference 
back to the checkpoint object manager, which is a se- 
cure system, to obtain a secure audit trail of work flow 
within the system. 

The checkpoint object manager herein described is 
especially useful when employed in parallel with an ac- 
tual workflow program because workflow software only 
moves work along, it does not provide a secure audit 
trail of the work itself, e.g. who handled each portion of 
the task, as what time, and with what disposition. The 
audit trail provided by the invention includes a digital sig- 
nature that provides robust and detailed authentication 
characters, such that each person in the work flow is 
readily identified with the task they performed. 

Thus, the person doing a task takes it to a certain 
point and then checks it into the checkpoint object man- 
ager. The checkpoint object manager is provided with a 
list of supervisors within the system who can authorize 
transactions. Such supervisory management of system 
security can be one-to-one, i.e. a single manager for the 
checkpointed employee; or it may be a set of managers 
who are contacted by the checkpoint object manager, 
any one of which can check-in to the checkpoint object 
manager, review and approve the transaction in ques- 
tion, and then release the transaction back to the check- 
pointed employee, via the checkpoint object manager. 

In practice, when an employee reaches the point tn 
the work flow, for example filling out screens by putting 
in names and addressees, where the present part of the 
task is finished, then the employee indicates this portion 
of the task is complete and ready for checkpointing, e. 
g. the employee pushes a button requesting approval. 
At this point, the employee's display may go blank and 
the employee goes on and does something else while 
waiting for the approval. What happens when approval 
is requested is that the request is encapsulated into a 
checkpoint object and reg istered into the checkpoint ob- 
ject manager. As discussed above, the checkpoint ob- 
ject manager only accepts authorization from appropri- 
ate supervisors. Such supervisors may have a pass- 
word or a digital signature that they enter into the system 
to indicate to the system that they are who they say they 
are. 

Typically, a password is something very personal 
and private to the supervisor that is not easily duplicat- 
ed, e.g. a smart card. For example, the smart card may 



be a manager-of-the-day smart card, where the super- 
visor logs in on the system as the manager of the day. 
The next day someone else is manager of the day. and 
even though the previous manager of the day can still 
5 log in on the system, only without the privileges of the 
manager of the day. The system always, through each 
supervisor, keeps an audit trail of all authorizations, 
such that if there is an irregularity in the system, there 
is a record of which manager and which clerk, for exam- 
w pie, were involved. It is then possible to perform an audit 
of the system and determine why the wrong authoriza- 
tion was given. Additionally, the system records when 
the authorization tails. In this way it is possible to identify 
when employees are in collusion to defraud the system. 

75 
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An apparatus for monitoring step^y-step progress 
of security administration within an electronic work 
flow, comprising. 

a checkpoint object (15) that provides uniform 
characterization of milestone and/or transition 
states in administration activity, where object 
class definition is inherited by or refined to an 
administration activity object; and 
a checkpoint object manager (25) that is instan- 
tiated as a trusted third party object which man- 
ages state progression of checkpoint objects. 

The apparatus of Claim 1 , wherein said checkpoint 
object manager further comprises. 

an actbn (23) that resumes checkpointed ob- 
jects with their state either advanced, reversed, or 
unchanged. 

The apparatus of either of Claims 1 and 2, wherein 
the checkpoint object manager further comprises: 
an action (33) that assures that all check- 
points are logged and/or monitored. 

L The apparatus of any of Claims 1 to 3, wherein the 
checkpoint object manager further comprises: 

an action (23) that assures that all resump- 
tions are authenticated. 



5. The apparatus of any of Claims 1 to 4, wherein said 
checkpoint object (15) must checkpoint to said 

so checkpoint object manager (25) to obtain second 
party approval. 

6. The apparatus of any of Claims 1 lo 5, wherein said 
checkpoint object manager (25) provides any of 

55 second party review, escalated authorization re- 
quirements, and trusted audit facilities. 

7. The apparatus of any of Claims 1 to 6, wherein said 
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checkpoint object (15) may inherit an object class 
having any desired security administration at- 
tributes; and wherein any object that has these at- 
tributes, or that has inherited this class, can then be 
managed by said checkpoint object manager (25). s 

8. The apparatus of any of Claims 1 to 7. further com- 
prising: 

a task that may be performed as part of a proc- 
ess until it reaches a checkpoint, at which point the io 
process checks-in a checkpoint object to said 
checkpoint object manager (25), wherein said 
checkpoint object cannot be checked-out of said 
checkpoint object manager unless criteria that im- 
plement security administration policies are met. *5 



prise a pointer, then only a pointer is returned 
by said checkpoint object manager; and such 
that if the data comprise actual data, then the 
data are stored by said checkpoint object man- 
ager, and 

a CkPntSeal attribute that provides a trusted 
seal of current checkpoint object information. 

12. The apparatus of any of Claims 1 to 11, said check- 
point object (15) further comprising at least the fol- 
lowing action (23): 

a SeaLCkPntObj() action that computes a 
CkPntSeal attribute, where said CkPntSeal at- 
tribute provides a trusted seal of current checkpoint 
object information. 



9. The apparatus of any ol Claims 1 to 8, wherein said 
checkpoint object (1 5) allows suspension of a task, 
and said task may not resumed, except as author- 
ized. 20 

10. The apparatus of any of Claims 1 to 9, wherein said 
checkpoint object manager (25) escalates said 
checkpoint object (15) upon failure to resume a sus- 
pended task, either by receiving authorization and/ 2S 
or by returning to said task within a predetermined 
time. 

11. The apparatus of any of Claims 1 to 1 0, said check- 
point object (1 5) further comprising one or more of 30 
the following attributes (22): 

an applicationID attribute which identifies a 
name of an application that sets the context for 
this checkpoint; 35 
an ApplCkPntState attribute that indicates a 
state of an object when a checkpoint is per- 
formed; 

an ApplResumeState attribute that indicates a 
state with which an object should resume; 40 
an ApplAuthRuie attribute which is a signed au- 
thorization rule that is used by a current appli- 
cation, where said rule is indexed by states 
such that it governs authorization entitlements 
as said application's activities progress; 45 
a CkPntTimeLimit attribute that indicates a time 
limit that said checkpoint object may reside with 
said checkpoint manager, where if said lime 
limit is exceeded, said checkpoint manager is- 
sues an event to signal escalation of checkpoint 50 
attention; . 

a CkPntObjMgrlD attribute that records a list of 
all checkpoint object managers that have cur- 
rently serviced a checkpoint object; 
a CkPntDataPntrs[] attribute that provides a list ss 
ol pointers to current checkpoint data, where 
said data is stored as binary data by said check- 
point object manager such that if the data com- 



13. The apparatus of any of Claims 1 to 12, said check- 
point object manager (25) further comprising one or 
more of the following attributes (32): 

an ApplCkPntCount attribute that provides a 
count of checkpoint objects that are currently 
checkpoihted by the checkpoint object manag- 
er; and 

an AppIC kPntList[] attribute that provides a 
non-ordered list of checkpoint objects that are 
currently checkpoinled by the checkpoint ob- 
ject manager. 

14. The apparatus of any of Claims 1 to 13, said check- 
point object manager (25) further comprising one or 
more of the following actions (33): 

a Find() action that searches an ApplCkPntList 
attribute lor objects that match a criteria of 
passed arguments, where said ApplCkPntList 
attribute provides a non ordered list of check- 
point objects that are currently checkpointed by 
the checkpoint object manager; 
a Delete() action that is adapted to delete a 
checkpointed object, where authorization re- 
quired for the Delete() action is associated with 
administration entitlements for said checkpoint 
object manager; 

a CkPnt() action that checkpoints an applica- 
tion object that contains the CkPntObj class be- 
havior, where checkpointing an object captures 
all CkPntObj attributes and checks a suspend- 
ed object in its present state into a CkPntObjM- 
gr datastore, where said CkPntObj Mgr holds 
this information, and waits for a next application 
service to check out said object and resume 
processing; 

a Resume() action that passes all checkpoint 
attributes for an identified checkpointed object 
to a calling object after first passing authoriza- 
tion rules to said calling object; and 
a ReportO action that produces at least one re- 
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port drawn from checkpoint object manager 
log/a ud it files and/or currently checkpoint ed 
data. 

1 5. A method for monitoring step-by-step progress of 
security administration within an electronic work 
flow, comprising the steps of: 

providing a checkpoint object that provides uni- 
form characterization of milestone and/or tran- 
sition states in administration activity, where 
object class definition is inherited by or refined 
to an administration activity object; and 
providing a checkpoint object manager that is 
instantiated as a trusted third party object which 
manages state progression of checkpoint ob- 
jects 
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NAME: 
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ATTRIBUTES: 

Application ID 
ApplCkPntState 
ApplResumeState 

22— \~ ApplAuthRule 
CkPntTimelimit 
CkPntObjMgrlD 
CkPntDataPntrsG 



23-f ACTIONS: 

Seal_CkPntObj() 



Fig. 2 
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NAME: 
CkPntObjMgr 



25 



ATTRIBUTES: 

ApplCkPntCount 
ApplCkPntList[] 



33 



ACTIONS: 

Find() 

Delete() 

CkPnt() 

Resume() 

Report() 



Fig. 3 
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(54) Security administration for electronic data processing 



(57) An object oriented tool monitors the step-by- 
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ministration activity, and which may be inherited by or 
refined to an administration activity object. A checkpoint 
object manager that is instantiated as a trusted third par- 
ty object manages the state progression of checkpoint 
objects. As a result of checkpointing, checkpoint objects 
are resumed with their state advanced, reversed, or un- 
changed by the checkpoint object manager as appropri- 
ate. The checkpoint object manager also assures that 
all checkpoints are logged and monitored, and that re- 
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